Hinweise zu den importierten railML®-Daten

Aus folgenden railML®-Teilschemata werden Elemente in Visum übernommen:

  • Infrastructure
  • RollingStock
  • Timetable

Nachfolgend wird erläutert, welche Elemente der einzelnen Teilschemata importiert werden und wie der Laufweg in Visum anhand der railML®-Daten ermittelt wird.

Zuordnung der Operation Control Points zu Haltepunkten

Aus dem Teilschema ‚Infrastructure‘ wird nur das Element ‚operationControlPoints‘ (OCPs) benutzt. Es enthält die im Fahrplan verwendeten Betriebsstellen. OCPs werden in Visum auf Haltepunkte abgebildet. Dazu wird je Eintrag die OCP-ID und das gewählte OCP-Korrespondenz-Attribut ausgelesen und in den Werten des Haltepunkt-Korrespondenz-Attributs nach diesem Attributwert gesucht. Alle passenden Haltepunkte werden weiter untersucht. Kommt der Wert nicht vor, kann der OCP nicht zugeordnet werden und er wird in der Protokolldatei und im Meldungsfenster ausgegeben. Normalerweise ist nur ein Teil der OCPs im Visum-Zielnetz vorhanden. Der Import scheitert nicht, wenn ein OCP nicht zugeordnet werden kann. Es gibt aber eine Warnung mit der Möglichkeit, den Import abzubrechen, wenn ein verkehrlich relevanter OCP nicht zugeordnet werden kann. Ein OCP gilt dabei als verkehrlich relevant, wenn sein Element ‚propService‘ angegeben und darin das Attribut ‚passenger‘ wahr ist.

Gibt es mehrere Haltepunkte im Zielnetz mit passendem Wert des Korrespondenzattributs, kann die genaue Zuordnung abhängig von Gleisinformation erfolgen. Ist die Verwendung von Gleisinformationen innerhalb der Betriebsstelle (OCP) abgeschaltet oder enthalten die Haltepunkte im Korrespondenzattribut für Gleisinformation ebenfalls gleiche Werte, versucht Visum, wenn die beiden benachbarten OCPs eindeutig zugeordnet werden können, mittels Kurzwegsuche einen der in Frage kommenden Haltepunkte auszuwählen. OCPs mit mehrdeutiger Haltepunktzuordnung werden in der Protokolldatei aufgeführt.

Ein Import bei nicht zugeordneten relevanten OCPs kann dazu führen, dass betroffene Fahrten Halte verlieren oder in mehrere Fahrten zerfallen.

Auch 'trainPart'-Elemente mit nur einem im Zielnetz zugeordneten OCP können importiert werden, wenn sie im Rahmen von 'commercial trains' auftreten, deren Laufweg insgesamt mindestens zwei gültige OCPs umfasst und so die entsprechenden 'trainPart'-Elemente durch andere 'trainParts' verlängert werden.

Ermittlung der Fahrzeuge (aus RollingStock)

Aus diesem Teilschema werden die Fahrzeuge (‚formation ID‘) übernommen.

Für Fahrplanfahrtabschnitte können Sie (im Register Attribute für Fahrplandaten) einen Text in ein festzulegendes Attribut speichern, der die "formation" repräsentiert. Dieser Text liefert die an der "formation" angegebenen "vehicles". Sind die railML®-Attribute für "vehicle" in der railML®-Datei angegeben, wird alsText description ausgegeben, ansonsten name. Ist auch dieser nicht angegeben, wird die id ausgegeben.

Optional können auch Fahrzeugdaten aus den Teilschemata ,vehicles' und ,formations' importiert werden. Dabei werden ,vehicles' zu Fahrzeugeinheiten und 'formations' zu Fahrzeugkombinationen. Am Fahrplanfahrtabschnitt wird dann die Fahrzeugkombination gesetzt, die im ,trainPart' (aus dem der Fahrplanfahrtabschnitt entstanden ist) referenziert wurde (railML-Attribut ,formationRef').

Enthält eine railML®-Datei eine 'formation' ohne Bezug zu 'vehicles', wird eine Platzhalter-Fahrzeugeinheit eingefügt, sodass die Fahrzeuginformation im Zielnetz verwendet werden kann.

Ermittlung der Fahrplanfahrten

Fahrplanfahrten und die dazugehörigen Objekte der Linienhierarchie in Visum werden aus den ‚train‘-Elementen aus dem railML®-Datenbestand erzeugt. Diese ‚train‘-Elemente tragen selbst keine Information zum Laufweg, sondern binden sogenannte ‚trainPart‘-Elemente ein. Diese tragen Informationen zum Laufweg und den Zeiten sowie – optional – zum Verkehrstag, zu Fahrzeugen, zum Betreiber, zur Linie und zur Kategorie. Ein ‚train‘-Element enthält dabei 1 bis n ‚trainPartSequence‘-Elemente, die wiederum 1 bis n ‚trainPart‘-Elemente referenzieren. Jedes ‚trainPartSequence‘-Element steht für einen örtlichen Abschnitt, die darin angezeigten ‚trainPart‘-Elemente sind Fahrzeuggruppen / Zugteile, die diesen örtlichen Abschnitt gemeinsam zurücklegen. Dementsprechend müssen die ‚ocptts‘, also die Orts- und Zeitangaben, an den nebeneinander in einem ‚trainPartSequence‘-Element auftretenden ‚trainParts‘ übereinstimmen.

Diese Konstruktion ermöglicht zwei Sichten auf die gleichen Daten. Sie werden von Zügen des Typs ‚operational‘ und Zügen des Typs ‚commercial‘ realisiert. Ein Zug vom Typ ‚operational‘ beschreibt die Netz-Sicht, bei der zu jedem Zeitpunkt an jedem Ort nur ein Zug sein kann. Fahren mehrere Zugteile gemeinsam (Koppeln, Kurswagen etc.), gibt es nur einen operational train, der auf diesem örtlichen Abschnitt – also in dieser ‚trainPartSequence‘ – mehrere ‚trainParts‘ bindet.

Commercial trains

Der commercial train beschreibt die verkehrliche Sicht. Bei dieser Sichtweise nimmt jede Fahrzeuggruppe einen definierten Weg, möglicherweise über mehrere Zugnummern hinweg. Gemeinsam verkehrende Fahrzeuggruppen liegen daher in getrennten commercial trains vor.

In Visum wird jeder ‚commercial train‘ zu einer oder mehreren Fahrplanfahrten.

Der Laufweg einer Fahrplanfahrt, also die Daten ihrer Linienroute und ihres Fahrzeitprofils, ergibt sich abschnittsweise aus den Laufwegsdaten der eingebundenen ‚trainPart‘-Elemente. Dabei werden die ‚trainParts‘ – bis auf wenige Ausnahmefälle – zu Fahrplanfahrtabschnitten in Visum.

Die Daten einer Fahrplanfahrt werden aus einem ‚train‘-Element vom Typ ‚commercial‘ ermittelt, indem die ‚trainPartSequence‘-Einträge nacheinander wie folgt abgearbeitet werden:

  • Zunächst werden solche ‚trainParts‘, deren ‚category‘ nicht unter den einzulesenden Kategorien ist, ausgefiltert. Außerdem werden auch alle ‚trainParts‘ überlesen, deren Verkehrstag im vorgegebenen Filterzeitraum nicht verkehrt.
  • Ist die ‚trainPartSequence‘ nicht leer und gab es bisher noch keinen Laufweg, wird das Verkehrssystem der Fahrplanfahrt festgelegt als das Verkehrssystem, welches der railML®-category‘ zugeordnet ist, zu der das erste ‚trainPart‘-Element gehört.
  • Gibt es bereits einen Laufweg aus vorherigen 'trainPartSequences', wird geprüft, ob das der Kategorie des 'trainPart' zugeordnete Verkehrssystem mit dem der Fahrplanfahrt übereinstimmt. Falls nicht, wird eine neue Fahrplanfahrt angelegt. Die Fahrplanfahrten werden mittels Durchbindung verbunden.
  • Ist die ‚trainPartSequence‘ des ‚train‘ nach der Filterung leer, wird sie ignoriert. Gab es zuvor bereits eine nicht-leere ‚trainPartSequence‘ für die aktuelle Fahrt (dann hat die Fahrt bereits einen nicht-leeren Laufweg), wird eine neue Fahrt angelegt. Es entstehen dann also mehrere Fahrten aus dem gleichen commercial train.
  • Ist die ‚trainPartSequence‘ nicht leer, wird für das erste gefundene ‚trainPart‘-Element der Laufweg ermittelt (die anderen ‚trainParts‘ müssen einen übereinstimmenden Laufweg haben).
  • Dazu wird zunächst für jedes Auftreten einer Betriebsstelle im Laufweg (repräsentiert durch ein ‚ocptt‘-Element) die Betriebsstelle (OCP) einem Haltepunkt in Visum zugeordnet. Dies erfolgt durch Vergleich der Inhalte des Korrespondenzattributs auf Quellseite (railML®-Daten) und auf Zielseite (Visum-Haltepunkt-Attribut). Gibt es mehrere infrage kommende Haltepunkte und wird Gleisinformation verwendet, wird derjenige Haltepunkt verwendet, der die angegebene Gleisinformation in seinem zweiten Korrespondenzattribut aufführt. Gelingt die Zuordnung für eine Betriebsstelle nicht, wird sie aus dem Laufweg entfernt.
  • Ankunfts- und Abfahrtzeiten werden aus den unterhalb des ‚ocptt‘-Elements angeordneten ‚times‘-Elementen entnommen. Die ‚times‘-Elemente können mehrfach aber mit jeweils einem anderen ‚scope‘ auftreten. Für die Festlegung der Zeiten werden die ‚scopes‘ ausgewertet: Folgende ‚scopes‘ sind möglich:
  • published
  • scheduled
  • calculated
  • actual
  • earliest
  • latest
  • userdefined (in railML© können beliebig viele benutzerdefinierte ‚scopes‘ auftreten, diese werden in Visum unter einem Scope-Typ „benutzerdefiniert“ zusammengefasst.)

    • Die Priorität der ‚scopes‘ für die Auswertung können Sie festlegen. Kann kein passendes ‚times‘-Element gefunden werden (weil es z.B. gar keines gibt), hat der Haltepunkt keine Zeiten, d.h. in Visum wird für den Haltepunkt nur ein Routenpunkt angelegt, aber kein Fahrzeit-Profilpunkt. Gibt es nur einen Zeitwert (in der Regel die Abfahrt), wird dieser Wert für Ankunft und Abfahrt übernommen.

  • Wird auch Streckeninformation verwendet, werden von jedem Haltepunkt im Laufweg ausgehend Strecken mit der angegebenen Streckennummer (im Sinne von Kursbuchstrecken, nicht Visum-Streckennummer) und Richtung gesucht und dadurch der Weg zum nachfolgenden Haltepunkt genau festgelegt. Werden keine passenden Strecken gefunden, erfolgt eine Kurzwegsuche im Zielnetz zum nachfolgenden Haltepunkt.
  • Erfolgt der Import ohne Nutzung von Streckeninformationen, erfolgt eine Kurzwegsuche von jedem Haltepunkt zu seinem Nachfolger im Laufweg.
  • In jedem Fall bilden die gefundenen Wege zwischen den Haltepunkten zusammen die Linienroute.
  • Aus jedem ‚trainPart‘-Element einer ‚trainPartSequence‘ entstehen ein oder mehrere Fahrplanfahrtabschnitte. Für Fahrplanfahrtabschnitte können Sie einen Text in ein festzulegendes Attribut speichern, der die "formation" repräsentiert. Dieser Text liefert die an der "formation" angegebenen "vehicles". Sind die railML®-Attribute für "vehicle" in der railML®-Datei angegeben, wird alsText description ausgegeben, ansonsten name. Ist auch dieser nicht angegeben, wird die id ausgegeben. Optional können auch Fahrzeuginformationen aus den railML®-Daten 'vehicles' und 'formations' gelesen werden. Dabei werden 'vehicles' zu Fahrzeugeinheiten und 'formations' zu Fahrzeugkombinationen. An jedem Fahrtabschnitt wird genau eine 'formation' referenziert.
  • Im Normalfall ist jeder der Fahrplanfahrtabschnitte ausgedehnt über genau den Teil des Laufwegs, der von dieser ‚trainPartSequence‘ stammt, und mit dem Verkehrstag des ‚trainPart‘-Elements versehen.
  • Eine Ausnahme bildet der Fall, wo der Wechsel von einer ‚trainPartSequence‘ zur nachfolgenden mit einer Durchfahrt (‚ocptt‘ vom Typ ‚pass‘) zusammenfällt. Im Datenmodell von Visum kann ein Fahrplanfahrtabschnitt nur an einem Halt beginnen oder enden. Deswegen erstrecken sich in diesem Fall die Fahrplanfahrtabschnitte über den mit einer Durchfahrt verbundenen ‚trainPartSequence‘-Wechsel hinweg. Es kommt dann zu Verzerrungen der Daten, wenn die Zuggarnitur (‚formation‘) oder der Verkehrstag dort wechselt. Dies ist aber als Datenfehler in den Eingangsdaten anzusehen.
  • Am ‚ocptt‘-Element gibt es das Attribut ‚ocpType‘. Möglich sind hier die Ausprägungen begin, end, stop und pass. Der ocpType pass kennzeichnet eine Durchfahrt am betrachteten Haltepunkt. Auch Durchfahrten können mit ‚times‘-Elementen versehen sein.
  • Für den Import nach Visum müssen die Zeiten an den Fahrzeit-Profilpunkten monoton aufsteigend vorliegen. Fahrzeiten an ‚ocptt‘-Elementen mit unterschiedlichen scopes können unterschiedliche Werte aufweisen. Deshalb kann es zu Konflikten zwischen aufeinanderfolgenden ‚ocptt‘-Elementen kommen. Verursacht ein Durchfahrtspunkt (‚ocptt‘-Element mit ocpType pass) einen Konflikt, so wird dieser nicht als Fahrzeitprofil-Punkt, sondern nur noch als Routenpunkt (und damit ohne Zeiten) importiert.

Ist eine Fahrplanfahrt einschließlich ihrer Fahrtabschnitte auf diese Weise konstruiert worden, werden Fahrplanfahrtabschnitte, die sich örtlich nicht überlappen, aber den gleichen Verkehrstag und gleiche Fahrzeuginformation (und weitere Information) tragen, zusammengefasst.

Operational trains

‚Train‘-Elemente vom Typ operational werden nicht als Fahrplanfahrten eingelesen railML-Attribute, die an ,operational trains' ausgewiesen sind, können in benutzerdefinierte Attribute an Fahplanfahrtabschnitten übernommen werden. Zu einem Fahrtabschnitt gibt es genau einen operational train, der den ‚trainPart‘ enthält, aus dem der Fahrtabschnitt entstanden ist. Sollte ein ‚trainPart‘ in mehreren operational trains gebunden sein, werden die Daten des operational trains mit dem kleineren alphanumerischen Schlüssel (ID des trains) übernommen.

Möchten Sie die Attribute eines operational trains auswerten, können Sie in Visum über die Relation der Fahrplanfahrt auf ihre Fahrplanfahrtabschnitte zugreifen und diese mit der gewünschten Aggregationsfunktion aggregieren.

Hinweis: Sie können die Anzahl der Kalendertage, in denen ein Fahrtabschnitt verkehrt, in ein Visum-Attribut des Fahrplanfahrtabschnitts ausgeben, um auf dieser Basis Hochrechnungsfaktoren zu bestimmen. Ordnen Sie hierzu im Fenster Import von RailML im Register Attribute für Fahrplandaten der TrainPart_NumValidDays das gewünschte Zielattribut zu oder legen Sie ein benutzerdefiniertes Attribut an (RailML®-Daten importieren).
Ermittlung von Kopplungen

Eine Kopplung entsteht in Visum, wenn zwei oder mehr ‚trainPart‘-Elemente aus verschiedenen ‚commercial trains‘ in einem ‚operational train‘ gemeinsam, d.h. innerhalb der gleichen ‚trainPartSequence‘ verkehren. Es werden also die ‚operational trains‘ ausgelesen und auf solche ‚trainPartSequence‘-Elemente hin untersucht. Für jede gefundene ‚trainPartSequence‘, die zu verschiedenen ‚commercial trains‘ gehörige ‚trainPart‘-Elemente enthält, wird eine Kopplung über dem durch sie beschriebenen Teil des Laufwegs erzeugt. Wird derselbe ‚trainPart‘ in zwei ‚commercial trains‘ verwendet, so entsteht daraus ebenfalls eine Kopplung.

Beispiel zur Filterung der Kategorien

Die Filterung der Kategorien ist nützlich, um in Visum normalerweise unerwünschte Zu- und Abführungen abzuschneiden. Ein typischer Zuglauf eines IC ab Hamburg beginnt beispielsweise nicht in Altona, sondern mit einer Fahrt als Leerreisezug (Lr) von Langenfelde nach Altona. Diese wird in railML® als eigener ‚trainPart‘ mit eigener ‚trainPartSequence‘ dargestellt und normalerweise ausgefiltert, sodass die Fahrplanfahrt in Visum tatsächlich erst in Hamburg-Altona beginnt und dann das Produkt IC hat und nicht Lr.

Ermittlung der Umlaufdaten

Visum-Umläufe werden aus den railML®-Attributen und untergeordneten Elementen des Elements ‚rostering‘ gebildet und der angegebenen Umlaufversion hinzugefügt. Dabei können mehrere Umläufe je ‚rostering‘-Element entstehen. Zu einem railML®-Umlauf ‚rostering‘ gehören in der railML®-Datei die untergeordneten Elemente ‚blockParts‘, ‚blocks‘ und ‚circulations‘. Die Angabe von ‚circulations‘ ist optional, ein Import nach Visum kann jedoch nur erfolgen, wenn ‚blockParts‘, ‚blocks‘ und ‚circulations‘ vorliegen.

Die ‚blockParts‘-Elemente entsprechen in etwa den Umlaufelementen in Visum. Sie besitzen keine Information über die Position im Umlauf, sondern nur eine Zeit. Jedes ‚blockPart‘-Element enthält das Attribut ‚mission‘. Folgende Ausprägungen sind möglich:

  • Fahrt als Referenz auf einen Zugteil: mission=timetable entspricht in Visum dem Umlaufelementtyp Fahrplanfahrt. Das ‚blockPart‘-Element muss ein Attribut trainPartRef enthalten.
  • Fahrt ohne Referenz auf einen Zugteil: mission=fullRun oder emptyRun entspricht in Visum dem Umlaufelementtyp Leerfahrt.
  • Dienst, der keine Fahrt ist: zum Beispiel Wartung, Tanken

Andere Aktivitäten als Fahrplanfahrt und Leerfahrt (alle "missions", die nicht dem Wert timetable, fullRun oder emptyRun entsprechen) werden als benutzerdefinierte Umlaufelement-Typen eingelesen.

Das ‚block‘-Element beschreibt alle Informationen für einen „Fahrzeugdienst“ und definiert eine beliebige Abfolge (‚blockPartSequence‘-Elemente) von Aktivitäten (‚blockPart‘-Elemente). Es entspricht am ehesten einer Darstellungsebene der Umlauf-Blockdarstellung oder auch nur einem Teil davon. Die Aktivitäten dieser Abfolge werden hintereinander geleistet, möglicherweise an mehreren Tagen des Kalenders. Die ‚blockGroupNumber‘ hat auf die Abbildung in Visum keinen Einfluss.

In dem Element ‚blockPartSequence‘ werden die referenzierten ‚blockParts‘ als Einzelaufgaben zu einem "Dienst" gruppiert. Dafür wird deren zeitliche Abfolge inklusive Vor- und Nachbereitungszeiten festgelegt. Innerhalb einer ‚blockPartSequence‘ können mehrere ‚blockPart‘-Elemente referenziert werden. Liegt dieser Fall vor, so entscheiden die in den ‚blockParts‘ angegebenen Zeiten über die zeitliche Reihenfolge der ‚blockParts‘.

In ‚circulation‘-Elementen werden "Dienste" (blocks) zu einem Umlaufplan verkettet und sie geben an, an welchen Verkehrstagen welcher ‚block‘ verwendet wird und welcher ‚block‘ darauf folgt.

In den railML®-Umlaufdaten kann sowohl im ,rostering'-Element als auch im ,blockPart'-Element über die railML-Attribute ,formationRef' oder ,vehicleRef' auf Fahrzeugdaten verwiesen werden. Erfolgt der Import ohne Fahrzeugdaten, wird am Umlauf keine Fahrzeugkombination gesetzt. Erfolgt der Import mit Fahrzeugdaten und in den railML®-Umlaufdaten ist die ,formationRef' gesetzt, wird jedem Umlauf die Fahrzeugkombination zugewiesen, die der in der ,formationRef' angegebenen ,formation-ID' entspricht. Erfolgt der Import mit Fahrzeugdaten und in den railML®-Umlaufdaten ist die ,vehicleRef' gesetzt, wird eine zusätzliche Fahrzeugkombination angelegt, die nur aus der referenzierten Fahrzeugeinheit besteht und im Namen durch ein vorangestelltes „railML-vehicle-“ gekennzeichnet ist.

Unabhängig davon, ob Sie Fahrzeugdaten importieren, können Sie für Umläufe einen Text, der ,formation' oder ,vehicle' repräsentiert, in einem Attribut speichern (Register Attribute für Umläufe , Information "Rostering_Formation", "Rostering_Vehicle", "BlockPart_Formation", "BlockPart_Vehicle"). Diesen Text liefert das an ,formation' oder ,vehicle' angegebene railML®-Attribut "name". Ist "name" nicht vorhanden, wird das railML®-Attribut "code" verwendet.

Optional können nur Umlaufdaten ohne Fahrplandaten importiert werden. Die Umlaufinformationen werden beim Import bestehenden Fahrtabschnitten zugewiesen.